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ABSTRACT 


Remarkable technical advances in cell phones and smart phones have resulted in a 
worldwide marketplace permeated by mobile devices. These capabilities, in combination 
with increasing consumers demand to share information show the need for utilizing the 
mobile devices more efficiently. But, within a distributed network of mobile devices like 
TwiddleNet, the two most limiting resources are still battery power and bandwidth. By 
distributing only small sets of data that represent the actual content, use of these 
resources can be reduced. The information tags can be sent throughout the network, 
reducing the amount of traffic to share the information. But, once the content itself is 
shared, the workload on the mobile servers can quickly exceed the mobile device’s ability 
to perform. This thesis offers an algorithm that will conserve battery power and 
bandwidth, depending on demand and device capabilities. Once a certain limit of 
bandwidth usage, or a certain battery level, is reached, the algorithm will select the 
content that will most efficiently relieve these two resources and temporarily upload it to 
a proxy server that will serve the content on its behalf. This “smart,” temporary caching 


will last as long as the bandwidth or battery level limits are exceeded. 
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I. INTRODUCTION 


In 2007, the market penetration of cell phones and smartphones had already 
reached 110% in Europe,! meaning, statistically, everybody owns a mobile device and a 
number of people use more than one device. A 2007 Bridge Ratings Industry Study? 
projected that 70% of the U.S. population owns a cell phone. At a population of 300 
million, that means 210 million cell phone users. With current population growth, that 
number becomes 300 million users by the year 2015. Worldwide, a recent UN report 3 
suggests 2008 will see 50% of the earth’s population using a mobile phone. Although the 
developed Western nations have the highest mobile phone rates, China estimates one 
billion cell phone subscribers in 2008, and many other non-Western nations are 


experiencing rapidly rising rates of use as well. 


What do these statistics mean from a technology and social science standpoint? It 
means being able to take advantage of the ubiquitous presence of mobile devices to 
advance technologies that will extend the movement of information, securely and rapidly, 
with enormous potential for new applications. The flow of data, privately and directly 
from mobile device to device could be used in emergency situations for civilian, 
government, and military organizations. Consider Hurricane Katrina in August 2005 or 
the tsunami of Southeast Asia in December 2004. The ability to instantly and reliably 
communicate critical information across a wide range of organizations could aid in 
property and life-saving responses. Consider as well the market for applications in the 
social networking arena. The popularity of social websites and text messaging point to a 
large and growing market for sharing information, music, pictures and more. Peer—to- 
peer communication, with privacy concerns alleviated by essentially excluding the public 


domain, is of value to consumers. As cell phones evolve into “smartphones” and users 


! Daniel dos Reis, http://www.dosreis.de/2007/01/20/excellent-article-about-mobile-phone-users-ww/, 
retrieved April 2008. 


2 Bridge Ratings LCC, http://www.bridgeratings.com/press_05.09.2007-Mobilphone.htm, retrieved 
June 2008. 


3 Romow, http://www.romow.com/shopping-blog/mobile-phone-use-reaches-50-worldwide/, retrieved 
June 2008. 


become more comfortable with these technical advances, the need for secure, easy to use 
technologies and services will continue to expand. The possibilities for market 
opportunity are almost limitless with a system that can solve privacy, ownership, and 


bandwidth issues whether a user uses a mobile device or a home PC. 


Smartphones offer more capabilities then telephony alone. These devices have 
multimedia features like taking pictures and recording videos. They are able to record 
voice notes or store text files. In today’s phones, storage capacities in Giga Bytes and 
processor speeds of more then 500 MHz are common. Soon Terabytes of storage and 
Giga Hertz processors will be the standard. Many devices have a Global Positioning 
System (GPS) chip built in as well, and typically possess more than one networking 
connection. In addition to the telephone network infrastructure for voice transfer, the 
devices often offer data transmission via the telephone system*, Wi-Fi> and Bluetooth®. 
Powerful operating systems run general purpose applications and interface with the user 
via sound or multicolor touch screen displays. Wi-Fi phones, Wi-Fi cellular dual-mode 
phones and PDAs (Personal Digital Assistants) allow users to take full advantage of 
heterogeneous radio technologies. With the advance of third-generation (3G) cellular 
networks, data transfer capabilities can enable live video streaming. All of these 
capabilities are packaged in a single handheld device no bigger than a wallet! For the 
remainder of this thesis, we will refer to these devices as “smartphones” or “mobile 


devices” interchangeably. 


In conjunction with technical advances, user behavior has also changed 
significantly in the past couple of years. Five years ago, cell phones were mainly used for 
telephony or text messaging, but consumers today are utilizing more features of these 
devices. One reason is that the capability and the quality of those features dramatically 


increased. One should think about the quality of pictures one can take with a low-cost 


4 Most common in the U.S. is the Global System for Mobile communications technology. It is 
considered second Generation (2G) wireless communication. 3G technology is already available but not yet 
widespread in the U.S. 


5 Name used for IEEE 801.11 a, b, i and n standards. 


6 Personal Area Network (PAN) technology that allows short-distance (less than 300’) wireless 
communication. 
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device. Many teenagers have their first experience with digital photography using their 
cell phones. Another reason is a social aspect, meaning that staying in touch with friends 
and family and sharing information has become a part of our daily lives, every where and 
every time we want. But the data sharing is mostly limited to services like multimedia 
message service (MMS) where media messages are sent like text messages using the 
telephone infrastructure or uploading the content to web pages, later using the PC at 
home. While the latter is time consuming and content sharing is delayed, the first is very 
cost intensive and limited to a small number of recipients. A better use of the mentioned 
device capabilities would be to support content sharing in real time and without third- 


party services usage. 


TwiddleNet is a software application designed to support this advanced, real-time, 
secure file sharing. In TwiddleNet, each smartphone not only acts as content creator, but 
also serves user requests directly in a peer-to-peer fashion. While in the conventional 
client server model the user uploads or sends the whole file to the recipient, TwiddleNet 
only sends characterizing metadata, which reduces network load significantly. If the 
recipient actually wants the file, she then downloads the file directly from the source 
mobile device. Instead of only pulling the content from a third-party webpage, 
TwiddleNet adds a push capability to the network that allows for real-time alerting at 
content creation, without needlessly sending huge amounts of data into the network. The 
link between the devices is the TwiddleNet portal. The portal is a central repository for 
knowledge about participating user devices; it forwards received metadata alerts to the 
recipients or acts as temporary content server in lieu of a mobile device. A mobile device 


can act as the portal as well, as described by Rimikis [1]. 


TwiddleNet provides an advantage over existing Internet-based methods of 
communication by acting as client and as server. Whereas the content creator currently 
gives up ownership once placing that content out for public viewing, with TwiddleNet the 
ability to distribute data, to push and pull, while maintaining control, is advantageous to 
the user. Users can control who is eligible to receive and download their content because 
that happens on the user’s mobile device. In addition, TwiddleNet supports a caching 
feature that allows the user to temporarily upload the content to the portal. The portal 


a) 


then serves the cached content to minimize power consumption and frees bandwidth 
capabilities on the user’s device. If the user decides to either serve the content again from 
her device or not to share it at all, the portal will delete the file and stop serving or 
advertising it. This ability to control your own content is an improvement over today's 
client server architecture. By protecting and controlling data transmission TwiddleNet 


becomes a privacy and ownership differentiator from other methods of communication. 


A. OBJECTIVES 


This thesis focuses on making TwiddleNet devices more power efficient. Since 
TwiddleNet end-user devices are battery-powered, conserving power is important. As 
described above, end-user devices act as content servers, and this uses their batteries. For 
content which is high demand, it can be a problem — the user device will suffer a high 
loss of power because of a many other users want the content that resides on it. One of 
the ways of ensuring that the power conserving capability of TwiddleNet is efficient and 
effective, is to cache popular content at the portal. Smart caching allows the device, 
depending on file size, battery level or workload, to tell the portal to serve the content on 


its behalf, while maintaining full ownership and control. 


In addition, this thesis offers improvements to the overall capabilities of 
TwiddleNet. The first version of TwiddleNet experienced highly unstable connectivity to 
the network and the portal. This problem will be addressed by improving the connectivity 
checking algorithm and introducing an address updating solution between the mobile 
device and the portal. A user-transparent address translation scheme that assures correct 
addressing independence of actual device network address (independent of device IP 
address) will be implemented. For better usability, a new graphical user interface (GUI) 


will be designed and implemented as well. 


B. TWIDDLENET USE SCENARIOS 


1. Government Organizations 


The devastation brought by Hurricane Katrina in southern sections of the United 


States can be used to demonstrate the potential application of TwiddleNet services in the 
4 


triage or humanitarian realm. In Katrina-affected areas, all communications infrastructure 
was destroyed, but the need for communication, especially in the first 48—72 hours, is 
essential to coordinate organization efforts. As depicted in Figure 1, TwiddleNet provides 
a fly-away kit that establishes the means of communication needed for first responders. A 
vehicle-mounted Wi-Fi router provides the needed front line Wi-Fi cloud and provides 
backhaul communication via satellite or point-to-point 806.16 networks. The triage teams 
will spread out and start collecting casualty data. This information will be shared within a 
team and with the backend central command center and hospital. When the patient arrives 
at the hospital, or even during transport, the personnel will have up-to-date information 
about the patient and critical time will be saved. TwiddleNet can provide the hospital 


with all needed information in advance of the patient arrival to allocate resources in an 


efficient and effective manner [2]. This particular scenario has been tested successfully 


during the COAST exercise in Thailand in 2008 [3]. 





Figure 1. | Mobile TwiddleNet Flyaway Kit 


2s Social Networking 


Envision the scenario where new parents want to inform a group of family and 
friends of their new arrival. Not only do they want to announce the baby's name and 
weight, they want to send a picture as well. Instead of making numerous calls or 


designating a main point of contact, who would then inform others, they have the ability 
5 


to send a message “alert” to the group. Maybe a few days later they want to send a video. 
The group of family and friends can communicate with each and share messages of 


congratulations. 


Can the parents who are not already set up on a web site to do this? Yes, but these 
web sites do not have the push capability that TwiddleNet does, eliminating the need to 
surf the Net. Considering that almost everyone has a cell phone, the security, ownership, 


privacy and convenience factors all add up to an easy-to-use, compelling service. 


With the “sandwich generation,”’? who are somewhat technically savvy, 
TwiddleNet offers benefits beyond email and cell phones. Alerts regarding medical 
conditions for elderly parents sent to the family group provide fast, efficient, real-time 
updates. At the same time, “keeping track” of their teenage children, who are highly 
technical and sharing news of their school events, friends and travels, provides an 


excellent communication tool. 
3. Business Opportunities 


Consider some of today's methods of marketing to consumers in the retail market. 
Grocery stores supply shoppers with a paper coupon for a product purchased that day for 
a similar product to be used on their next shopping visit. When a shopper logs into 
Amazon.com, a list of books is presented that Amazon deems to be of interest to that 
particular shopper based on previous buying habits. Email messages are sent notifying 
customers of special deals from furniture and home decorating corporations. These paper 
or Internet based marketing messages may no longer be useful to a shopper or may not be 
received in-time to make a buying decision. Those marketing pitches are based on 
previously gathered information, which may quickly become outdated. Imagine the value 
to a consumer to be able to sign up with specific retail or online stores of their choice and 
receive alerts of specials or sales based on their current needs as described by the 


consumer herself. And as those needs change in the future shoppers can update their 


7 Generation of people between 40 and 60 who care for their aging parents while supporting their own 
children. 


6 


profile as frequently as they like. The Friday Costco shopper with children might be sent 


an alert Thursday night listing specials on diapers and current children's books. 


Another potential, even more time-critical market would be the financial world. A 
user could have her group consist of her stockbroker, tax accountant, money manager, 
mortgage broker and spouse. Real-time private alerts relating to stock sales, investment 
opportunities, interest rates, and the tax implications to those financial decisions could be 


extremely valuable. 


These are just some examples to demonstrate how TwiddleNet could potentially 
be used in the real world to benefit individual consumers and government organizations 


alike. 


C. SCOPE 


The thesis will focus on finding the appropriate algorithm for the mobile servers 
to facilitate file caching in support of the TwiddleNet mobile-server network. 
Measurements will be made empirically to find battery power consumption values and 
bandwidth restrictions for the test devices to define heuristics for the needed caching 


algorithm. 


This algorithm will include only the device and the portal interaction. No further 
caching algorithms as referenced under [4] will be addressed. To accomplish this, a 
software implementation that automatically tracks user demand for content and battery 
life of the server, will be presented. The algorithm will be based on general research 


questions to include: 
1. How is caching currently accomplished? 
2. What are the decision factors for caching? 
3. What will be the thresholds for the decision criteria? 
4. How can control data communication efficiently be implemented? 


5. How to implement caching in an efficient manner? 


D. ORGANIZATION 


The remainder of the thesis is organized as follows. Chapter II provides 
background information on the key areas of caching within distributed networks, power 
consumption, and bandwidth issues for mobile devices, and gives a broad overview of 
TwiddleNet components. Chapter III describes in detail all aspects of implementation of 
the “smart caching” algorithm. Chapter IV provides the conclusion and describes future 


work. 


Il. BACKGROUND 


A. TWIDDLENET 
i, TwiddleNet Components Overview 


TwiddleNet logically consists of ten components. The distinct blocks are 
displayed in Figure 2. This thesis focuses mainly on “smart caching,” but to understand 
the entire application, each component will be briefly described in the following 


paragraphs. “Smart caching” will be thoroughly discussed in Chapter III. 





Figure 2. TwiddleNet components 


a. Content Creation 


Content can be anything the device is capable of producing or handling, 
like a text file, an image, a video or a PowerPoint presentation. The content can be 
created on the device, i.e., taking a picture with the built in camera, or it can already 
reside on the device such as an e-mail attachment. The user has the choice of manually 
adding the content to the items list being shared or selecting the automatic sharing after 


creation. 


b. Tagging 


A tag contains metadata, be it general information such as the date, author, 
location (if GPS-equipped) or file size, or any other information the user would like to 
add. The process of tagging essentially maps the information to the content and makes 
organizing and searching information feasible in a scalable and organized fashion. The 
tag in general is significantly smaller than the content it represents. The information that 
is tagged to the content is stored in xml-documents8, which are also used to distribute the 


information within the network [5]. 


c. Data-Distribution 


TwiddleNet uses one central networking device, the portal, which is 
responsible for receiving content metadata from the content producer and alerting the 
clients who have signed up to receive this category of content [5]. The TwiddleNet 
internal communication between Clients and Portal (alerting, caching and administration) 
happens via an easy internal protocol running over Transmission Control Protocol (TCP). 
The actual content sharing is accomplished via Hypertext Transfer Protocol (HTTP). The 


reason to choose HTTP was compatibility to web browsers. 


8 XML = Extensible Markup Language. 
10 


d. Online Search 


If an alert is missed or a user wants to search for something else, 
TwiddleNet offers two ways to access information on the portal. A web-based browser 
application allows surfing to the portal and retrieves the desired information. 
Alternatively, the user can query the portal via the client application that runs on the 
mobile device. Both methods offer the ability to enter a query text and a query category 
such as “Author,” “Group” or “Keyword.” The search results are viewed in a similar 


fashion as the alerts, except that it is not real time, and the user has to “pull” the content. 


é. Network 


TwiddleNet uses Wi-Fi or GSM as carrier media. Both services use 
Internet Protocol (IP) addresses. Because each client also acts as the server, TwiddleNet 
requires a unique address scheme. To utilize TwiddleNet capabilities, each participating 
unit needs to have an Internet routable IP address. In addition, because the devices are 
mobile by definition, their IP address will frequently change. One limitation of the first 
version of TwiddleNet was that the actual IP address of the content creator was sent 
along with the alert. A receiver device would use that IP address to retrieve the content, 
yet, by definition, that mobile device’s address could be continually changing. This thesis 
implements an application-level address scheme that translates a unique user name to a 
potentially changing IP address. As localizing reference, the unique user name is sent 
within the alert as an author tag. To retrieve the desired content, the receiver first contacts 
the portal hosting the address translation service. Each device constantly monitors its own 
IP address and then informs the portal of changes. Therefore, the portal is always aware 


of the status of each client and its current IP address. 


Private network domains with non-Internet routable IP address ranges are 
only suitable if all participants belong to it or to connected private networks. The problem 
with private domains like a home network with an address such as 192.168.1.x, for 
example, is described as follows. To connect to the Internet, a network device, like an 


edge router, typically hosts a service called Port Address Translation (PAT) or Network 
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Address Translation (NAT)?. Both services translate the internal private IP address into 
an external Internet-routable IP address. This service is designed to send a message into 


the Internet and to receive data within that connection, as shown in Figure 3. 
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Figure 3. “PAT” in private LANs 


Because the TwiddleNet clients run as servers as well, a connection would 
not be initiated from the inside and, therefore, the firewall would drop these requests. 
Even if the router was instructed to forward a request on a certain port to a pre-assigned 
IP address in the private network, that would only apply to one TwiddleNet client. But, if 
two clients are within the same network, both listening on the same port for requests, the 
router would not be able to distinguish who would be the correct receiver, as displayed in 
Figure 3. Therefore, only an address scheme provided by IPv6 or IPv4 Internet-routable 


IP addresses would be able to easily solve this problem. 


9 Usually a private network has only one Internet routable IP address provided by the Internet Service 
Provider. Therefore to enable multiple hosts within the private network to connect to the Internet, the router 
assigns each connection a separate port number. When the answer returns from the Internet the router 
multiplexes the messages according its port number - IP address table (PAT). If the router has multiple 
routable IP addresses assigned by the Provider it will translate internal address to external address (NAT). 
Typically the NAT acronym is used to express the PAT and the NAT service. 
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Figure 4. “PAT” limitations with mobile servers 


A third proposed solution would be that once the client realizes it is on a 
private network, it will — in addition to the local, normal server operation — frequently 
contact the portal if there were requests for its unique username. The portal would 
function as a buffer zone that would keep a connection open to both devices and would 
relay the traffic between both devices. Because both connections were initialized from 


within the private network, the PAT/NAT scheme would work adequately. 


The GSM private network limitations have been addressed by [5]. They 
are similar to the private LAN limitations because the telephone companies use private 
domain addresses as well. The latest mentioned solution would be a suitable approach for 
that problem domain as well, or an additional proxy server would be needed that 


translates incoming requests to internal IP addresses. 
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f Account Administration 


One major improvement in the current TwiddleNet implementation is the 
user transparent address translation scheme that enables the network to keep track of the 
actual IP addresses, which are needed for the physical world, and the username-based 
information distribution, which is application layer controlled. The clients recognize any 
change of their connection status and will automatically inform the portal of their current 
address. The portal will now manage TwiddleNet traffic according to the stored 


information. For more detail, see Chapter III. 


Other important aspects are the client profiles. Clients may belong to more 
than one group: user X belongs to both group “Blue” and group “Red” or wants to 
receive alerts about a certain topic only. Using a relational database-based algorithm, a 
user would be alerted only for content from a fellow group member or about his 
requested content. One can see how important it is to track and to enable access 


depending on user profiles. 


g. Database Design 


The relational model described above in Account Administration implies the use 
of a relational database as the enabling infrastructure. This is discussed in the “Future 
Work” section of Chapter IV. Currently, only the username IP address scheme, the 
storage of the content metadata and the smart caching is implemented using database 


tables. 


h. Security 


Managing people’s private information is always a critical piece of the 
equation. Privacy and security are the cornerstones of the trust consumers have come to 
expect and demand in technology today. Currently, TwiddleNet uses the built-in security 
capabilities of the underlying network connection. For the Wi-Fi connection, that means 
Wired Equivalent Privacy (WEP) and Wi-Fi Protected Access with Pre Shared Key 
(WPA-PSK) using TKIP (the Temporal Key Integrity Protocol) to enhance data 
encryption. These are the limiting capabilities of the used HP iPAQ mobile devices. The 
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underlying data security in the GSM domain are those of General Packet Radio Service 
(GPRS,) which is used as the data transfer protocol in Global System for Mobile 
communications (GSM). TwiddleNet itself currently has no module to enforce 


confidentiality, integrity or authentication implemented. 


i. TNet Tool Box 


The TNet toolbox currently contains only one additional application. The 
“TNet Command Post” is a specialized client that will receive all alerts distributed 
through the TwiddleNet network and retrieve the corresponding content. This content 
will then be incorporated into a web site. As the name Command Post suggests, that 
central repository is used to house all collected data and display the relevant data to the 
command structure. In addition, the created web page has a search and wiki functionality 


to add comments or other information to the metadata. 


A future second application is a web-based administration interface to 
open and manage a TwiddleNet account. This interface is used rather then the 
TwiddleNet client application to reduce the complexity and the footprint of the software 
on the mobile device. This application is discussed further in the Chapter V “Future 


Work” section. 


B. POWER CONSUMPTION OF MOBILE DEVICES 


Like all mobile devices, smart phones suffer from their limited battery life. 
Adding wireless communication capabilities without a special and careful power- 
preserving design will accentuate the power problem. Wi-Fi was not originally designed 
for energy constrained handheld devices. As a result, the standby times of a handheld 
device with a Wi-Fi interface is significantly lower than what people typically experience 


with today’s cellular phones. 


Our test devices use the 801.11b Wi-Fi protocol. The advertised connection speed 
of 802.11b is 11 Megabits per second (Mbps), which is about 82.5 Mega Bytes per 
Minute (MB/min). That value is only achievable in a laboratory environment, with no 


interference and under ideal conditions. The mentioned transmission rate is the total 
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amount of data transmitted. That data consists of the overhead of the protocol and the 
actual payload that needs to be transmitted. This means we can realistically transmit 
significantly less real payload than 82.5 MB/min. In addition, there will always be 
interferences with other spectrums and collisions within the media, such that the actual 
sending capability is significantly reduced. For 802.11b, realistic peak throughput values 
are 4 to 5 Mbps which is equivalent to 30 to 37.5 MB/min under good conditions. Most 
802.11b networks typically run at 2 to 3 Mbps, which is about 15 to 22.5 MB/min. These 
bandwidths need to be shared under all devices connected, reducing the individual usable 
bandwidth again, but, on average, these values are still faster than broadband Internet 
connections, which normally operate at 0.5 to 2 Mbps peak for downloads [6]. The user, 
therefore, does not notice any slowdown due to the use of wireless. That is one reason 


why 802.11b is still very commonly used in private wireless networks. 


One way to reduce the amount of data the devices need to send, thereby reducing 
the energy demand, is to modify the Wi-Fi and/or upper-layer protocols to make the 
protocols themselves more energy-conserving [6,7]. For the TwiddleNet environment we 


are using off-the-shelf (OTS) devices and have no influence over the protocols used. 


Another approach seeks to minimize the unnecessary consumption of energy by 
energy inefficient network interfaces. It includes turning off the interfaces, or turning the 
interface into a low energy-consuming state, if possible, during time periods that the 
interface is not used to carry user traffic. The authors of [7] propose an algorithm that 
turns the interface off depending on a network-specific pattern of silent times within the 
current network. They predict that the down time could be up to 50% and only miss 1% 
of incoming traffic. Their traffic assumption is one visit per minute. For TwiddleNet, we 
assume an average number of ten visits per minute, adding up to 600 visits per hour or 
14,400 visits per day. That is an average visit rate for a popular webpage. A third and 
fourth approach to the energy problem by [9] and [10] is to turn off the antenna after a 
preset idle time or to add an additional low-energy antenna for control traffic to control 


the power-demanding Wi-Fi antenna. Turning off the antenna will not work for 
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TwiddleNet because the mobile devices act as clients and as servers. The latter would be 
an improvement if it will be implemented in the device and, therefore, will be available 
off the shelf. 

There are other areas as well that can be improved to save battery power; as 


depicted in Figure 4, however, Wi-Fi uses more than half of the available energy. 
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Figure 5. | Power breakdown for a mobile device. From [5] 








Reducing the needed transmissions is a key element in improving battery life and 
reducing energy demand. This thesis proposes an algorithm that significantly reduces the 
needed transmission by temporarily caching the content on the portal and letting the 


portal serve the content in lieu of the mobile device. 
C. CACHING IN WIRELESS NETWORKS 


The purpose of caching is to overcome “hot spots”!9 in a network. In the context 
of web pages, that means that the page gets so many requests that it becomes “swamped.” 
There are several approaches to overcome this problem. All deal more or less with 
creating multiple copies of the page on different servers and splitting up the workload for 
each single server. That is especially useful in private or corporate networks with 
multiple users. If every n user downloads the same page, the network has to transport the 
same data n times. To reduce this traffic it would be useful to download the page only 


once and cache a copy of it within the network. The most commonly used approach is to 


10 Hot spots occur any time a large number of clients wish to simultaneously access data from a single 
server. If the site is not provisioned to deal with all of these clients simultaneously, service may be 
degraded or lost. 
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route requests from multiple users through so called “proxy servers.” If the server has a 
current copy cached, it will serve the request, reducing the network traffic between itself 
and the home server. If it has not cached a copy, it will forward the request and cache the 
new page for future requests. This scheme is most beneficial for the upstream network 
with more users sharing the same cache or proxy-server. But then, the cache itself is 
likely to get swamped. To overcome that problem, another approach by [11] builds on the 
first idea, but increases the number of proxy servers. User requests would be sent 
arbitrarily to any proxy-server. If the page is not cached in that server, the protocol uses 
multicast messaging to query all other proxy-servers in that system, before it finally 
contacts the home server of that page. This approach creates a potentially high volume of 
overhead traffic that is not favorable in a mobile wireless environment with its limitations 
in bandwidth and battery power. An algorithm proposed by [12] reduces the needed 
multicast transmissions significantly, but leaves the necessity of providing multiple 
redundant proxy-servers. Based on tree theory, [13] proposes a hierarchy of caches 
similar to the hierarchy of name servers. The advantage of a cache tree is that a parent 
node cache receives page requests only from its children, ensuring that not too many 
requests arrive simultaneously. With increased scale and enough individual not cached 
page requests, the root node might get swamped because in the model the root node will 


receive and handle all requests for non cached sides. 


All approaches to the problem of hot spots discussed to this point duplicate the 
content and share the workload over multiple servers. In general, the assumption is that 
the server’s bandwidth is much bigger than the client’s bandwidth. Swamping happens 
due to the huge number of client requests. In TwiddleNet, that assumption does not hold 
because the available bandwidth of the server device is as big as or even smaller than a 
client that connects for download. This thesis proposes an algorithm that temporarily 
uploads the requested content to a device with more bandwidth available (TwiddleNet 
portal) to overcome possible hotspots on the device itself and on the wireless network it 


is connected to. The algorithm is explained in detail in Chapter III. 


18 


Hi. TWIDDLENET POWER CONSUMPTION TEST 


A. DEVICES 


For all testing purposes we used four iPAQ hw 6945 smart phones from Hewlett- 


Packard. 





Figure 6. iPAQ hw 6945 


The iPAQ hw 6945 is equipped with three different types of radios: Bluetooth, 
Wi-Fi and GSM. TwiddleNet only uses Wi-Fi 802.11b and GPRS over the GSM network 
to distribute data. 


B. SETUP AND CONFIGURATION 


We performed multiple tests over the Wi-Fi channel to collect data that will be 
used to find heuristics to implement a caching algorithm. To measure the power 
consumption of the mobile devices, we wrote two helper programs. One monitors the OS 
battery power level and measures the time between a percentage drop of available battery 
power. The other one simulates different download demands. The test content was a 
picture stored as jpg. The size was about | MB (1.053.799 Byte). 

For each test, we started with a fully charged battery, the display was at its 


brightest, the antenna setting was at max performance, CPU power was set to auto and 
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the network carried only test traffic. To allow the full use of the available bandwidth, 
only the serving client was attached to the wireless access point. The download 
simulation application was running on a PC that was connected via a CAT6 cable to the 
access point. The test configuration is displayed in Figure 7; the different download 
demands are displayed in Table 1. The measurements were limited to between 100% and 
50% because devices and batteries acted differently below that level. Some devices 


turned completely off just below 50%; some served till 0%. 





Figure 7. Test Network 


WiFi idle 
TwiddleNet idle 
(1.x 1MB)/min 
(5 x 1MB)/min 


(10 x 1MB)/min 
(15 x 1MB)/min 
(20 x 1MB)/min 
(25 x 1MB)/min 
(30 x 1MB)/min 





Table 1. Different download demands 


C. RESULTS 


Figure 8 shows the average time deltas between percentage drops of all four test 


devices. All test results are documented in Appendix A. 


As already expected from Figure 5, by turning on the Wi-Fi antenna, the average 


useable time between percentage drops is reduced to about half the standby time as 
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without Wi-Fi. Figure 9 shows the average results for the different download demands. 
One can easily see that with increased data transmissions, the battery lifetime is reduced. 
For a demand of 30 MB per minute, the tests indicated an average reduction in battery 


life of approximately 33%. All test results are displayed in Table 2. 
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Figure 9. | Power Consumption for various download demands 
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ae 1 45 . 0 
(1x1MBymin 0:01:43 97.96% 
aa 1MBy/min 0 M2 3 83.55% 


(20 x {MB)/min : ) 1: 73.46% 


Test 10 (30x 1MB)/min 0:01: 67.55% 





Table 2. Results of all Tests. 


The bandwidth was utilized only by downloads. Any other user interaction, like 
sharing new content or web surfing, would increase the power consumption because the 
available bandwidth needs to be shared between the separate processes and, therefore, 
increases the time needed for a single download. But, increased download times mean a 
longer time in a high-power demanding state. 

These test series show that reducing the data transmissions will improve battery 


life by up to one-third of the available lifetime for our test devices. 
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IV. SMART CACHING IN TWIDDLENET 


A. ENABLING FEATURES 


TwiddleNet represents a network of distributed mobile devices that act as clients 
and servers to achieve fast and easy content sharing in a peer-to-peer fashion. A central 
network device, called TNet-Portal, acts as the connecting entity. TNet-Portal basically 
keeps track of all users signed in and their current IP-address. It also acts as the contact 
node from where all users receive alerts about shared content. Because the TNet-Portal is 
typically a PC sized device with higher bandwidth and battery life capabilities, it can also 
act as a caching proxy for the attached mobile devices. This caching service is only 
available if the client is signed in to TwiddleNet and its bandwidth and battery life 
become vital limiting factors. The portal will not act as a normal server that shares 
content when the client is not online. The resulting algorithm is explained later in this 
chapter and represents the main contribution of this thesis. The next paragraphs describe 


improvements to TwiddleNet to allow the implementation of “smart caching.” 


1 FS TwiddleNet Client Sign-in 


To enable the portal to track participating users we implemented a sign-in 
procedure. The user account is already created using the web-based administration 
interface described in Chapter IV. That account contains a unique username and the 
password-hash. When the TNet-client application is started on the mobile device, the user 
has to first type the username and the associated password. The interface is shown in 
Appendix B. The username and the password-hash are sent to the portal via a TCP 
connection. If the database contains a matching username and password-hash pair, the 
current IP address will be stored in the database, and a positive acknowledgment is sent 
to the client. The application will start only after a valid sign-in. Access is denied in all 


other cases. 
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2. TwiddleNet Address Translation 


One key limitation of earlier versions of TwiddleNet was that it included the 
current IP address of the creator device into the alert sent to potential clients. As 
discussed previously, however, the IP address could change and render a future request 
for content impossible to deliver — even when the device was connected to the network 
(as its IP address would have changed). To overcome that limitation, we implemented 
into the client software an algorithm that constantly monitors the Wi-Fi connection. If the 
device receives a new IP address because it moved into another network, for example, it 
will automatically inform the portal of its new address. Therefore, the TNet-Portal can 
maintain a current list of signed-in users and their current IP addresses. To maintain an 
addressing scheme within TwiddleNet, users will receive unique user names. Those 
unique user names will be used by the portal, which translates them into the current IP 
address that is stored in the database. This translation is transparent to the user. To 
achieve transparency, we use the built in “temporary redirect” capability of HTTP, which 
we use for content request traffic to allow compatibility with normal net browsers. The 
redirect happens as part of the HTTP protocol and is not noticed by the user. Each client 
will always contact the portal if it requests a desired content. The request will contain the 
username of the creator and the content identification, which is currently the content 
name. The portal will look up the address in the database and redirect the HTTP request 
to the new address. Figure 10 shows the communication path for the case where the 
content creator device serves the content itself. 

In addition, before the username-IP address translation happens, the portal checks 
whether it has the requested content cached. If the content is cached at the portal, the 
portal will serve the request right away, without redirecting to the creator device. That 
communication is shown in Figure 11. A special case of a three-way redirect shown in 
Figure 12 can happen only if clients request content while a caching request from the 
content creator device to the portal happens almost simultaneously. Therefore, if for any 
reason a client would contact a creator device requesting cached content, the device 


application will redirect the request to the portal. 
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Figure 12. TwiddleNet Sharing and delayed portal caching 


B. CLIENT IMPLEMENTATION 


Figure 13 shows the states that content will traverse from being created to being 
cached at the portal. The different transitions represent the user choices when handling 
content in the current version of TwiddleNet. The “smart caching” algorithm focuses on 


the transitions between “shared state 1” and “shared state 2.” 
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Figure 13. System states from content creation to content caching 


The smart caching algorithm will address two key criteria for mobile devices: 


usable bandwidth and battery level. As discussed in Chapter II, bandwidth and battery 


power are limited resources, especially for mobile devices. 


Bandwidth will be addressed first. Depending on the protocol standard used for 
the devices, the actual available bandwidth will vary. No matter what protocol we use, 
however, the user has to decide how much of his available resource he is going to 


allocate to the task of serving. Other than serving shared content, she likely wants to 
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continue sharing new content, surf the web or place voice calls. For the current version of 
TwiddleNet client application, the user can select either 4, 4%, or %4 of the available 
bandwidth to dedicate to serve content requests. Because the theoretical limits of the 
available Wi-Fi standards are not a good basis for assigning limits to the application, we 
use the value of 30 Megabytes per minute for an 802.11b standard. This value was shown 
to be possible and feasible during the test series discussed in Chapter II. In addition, we 
assume the presence of at least three entities within one wireless network. The resulting 
decrease through put, due to collisions and interferences, provides a more realistic base 
value. Therefore, 10 Megabytes per minute of data transmitted is the base value that the 
smart cache algorithm uses. Once TwiddleNet moves to devices with better protocols like 


802.11g or higher, that base value will need to be adjusted. 


The client server counts all bytes of data transmitted and counts how often the 
content was requested. After one minute both counts will be reset to zero. If during that 
time the demand exceeds the user assigned limit of X Megabytes per minute, the 
algorithm will select the content which was requested most frequently and will cache it at 
the portal. Any additional requests will then be served by the portal, reducing the demand 
on the mobile device as long as the client is signed in. If that still leaves ambiguities, the 


first one in the list is selected. 


Heuristics: 1. Most often requested 
Zi Largest 
3. First in list 


Selecting the most frequent one first, rather than the largest one, will allow for reduced 
future demand on the device. As an example, we will share two pictures, one the size of 
two Megabytes and the other of 500 Kilobytes. The larger one was requested one time 
and the latter was requested 10 times per minute. If we were to cache the bigger one first, 
we would save the device only two Megabytes versus five Megabytes, than if we were to 


cache the content that was requested more often. 


The second factor to discuss is available battery power. The user has to select how 
much battery he is willing to assign to the task of serving. In Chapter II, we discussed 


how battery life can be reduced by up to 30% depending on download demand. Because 
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we cannot split up battery demand like we can split up bandwidth usage per minute, the 
user has to select a minimum battery level to ensure that power is used to serve content. 
In the current version the user can decide to either protect 1/3, 1/2 or 2/3 of the available 


battery power. 


The client device monitors the battery level and checks its value regularly every 
15 seconds. When the level reaches the user selected value of 34%, 50% or 67%, all 
shared but not cached content will be cached at the portal. From then on, the portal will 
serve the content as long as the client is signed in. If the device is recharged and the 
battery level increases again above the threshold, all cached content is automatically un- 
cached again. The idea is that the portal only temporarily caches the content if the mobile 
device reaches certain limits in bandwidth or battery level. At a power level of 30% the 
application will sign out at the portal to save the remaining battery power for more 
important tasks than TwiddleNet. Because the user is not participating in the network 
anymore, the portal will stop serving the cached content, but will keep a copy until the 


user signs back in. Then the portal resumes its task to serve the content. 


Both factors can execute the caching independently, whatever triggers first. In 
addition, the user always has the ability to manually cache or un-cache any shared 


content. 


C; PORTAL IMPLEMENTATION 


As previously mentioned, the main idea behind “smart caching” is to only cache 
content temporarily at the portal. The client device will send cache requests according to 
its own needs, meaning if bandwidth, battery level or user choice requires a temporary 
upload of the content. The client is going to un-cache its content again, once the required 
conditions are met, as discussed. The portal does not have any information about the 
reasoning behind these actions, but the portal needs to have a way to force the client back 
into self serving. The reason for this is that users may otherwise misuse the resources of 
the portal and always let the portal serve on their behalf. That would be just another 


classic client-server architecture, which is not the intended use of TwiddleNet. 
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TNet-Portal monitors the times when the cached content was last requested. When 
the time between last requests exceeds a given limit the portal contacts the client device and 
forces a un-cache of the content. If, at a later time, the mobile device needs to cache the 
content again because its smart caching algorithm triggered again, that cached content will 
again become part of the portal monitoring. We have used a timing-dependent versus 
demand-dependent approach because we could easily keep track of one value that represents 
the time when the content was last requested, compare it to the actual time to calculate the 
difference, and compare it to the given limit. Depending on the usage of TwiddleNet, for 
example a social network or a military scenario, the limit would definitely change. For 
example, in a social network the portal would only allow content to be cached for, say 24 


hours, versus a military network where the limit could be weeks. 


Depending on the resources available on the portal and the task the network has to 
fulfill, the limit is then chosen. Chapter V expands this discussion in the future work section. 
The current version of TwiddleNet portal, running in the test configuration, checks cached 
content every 15 minutes with a fixed time limit of 60 minutes. The algorithm will only 


handle content where the client is signed in and, therefore, a communication can take place. 


D. MISCELLANEOUS FEATURES 


To make TwiddleNet more user-friendly, we changed the graphical user interface 
(GUD) of the TNet-client application while maintaining all functionality. The current version 
of the graphical design is documented in Appendix B. The main improvement was to use tabs 
to switch between the different screens. That made the interaction faster and more intuitive 


for the user. 


We added a specific tagging interface that allows for specialized content tags. The 
current version has a specialized tag GUI for first responder medical triage teams. The idea 
behind the scenario was that a first responder team would take a picture of a patient. If 
special tagging option is selected the Triage GUI will be displayed to allow the user to collect 
information about the patient in question. Attached to the picture this information is 
embedded in the xml tag which will be used to alert follow on medical personal or a 
centralized Command Post. The GUI is based on the currently used paper tag and is 


documented in Appendix B. 
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V. CONCLUSIONS AND FUTURE WORK 


A. CONCLUSIONS 


TwiddleNet, a distributed mobile communication network, enhances the 
capabilities of smart phones and other mobile devices. This thesis discussed two key 
weaknesses of TwiddleNet: battery lifetime and bandwidth. We provided a solution to 
manage these inherent device limitations by implementing a demand and battery level 
dependent algorithm. A mobile device is then able to temporarily cache its content at the 


portal, thereby relieving itself from its demanding power and bandwidth tasks. 


To support true mobility, we implemented a user-transparent username-IP address 
translation scheme, which is a key feature of the distributed network. It allows for sharing 


of content even with constantly changing IP addresses. 


We also improved the graphical user interface for easier interaction between user 
and device, and provided an extended tagging interface, which is specialized for triage 


operations during humanitarian relief scenarios. 


The current version of the TwiddleNet network is a robust mobile file-sharing 
infrastructure that provides data distribution, general or special tagging, and efficient 
resource usage of mobile devices. Especially in the mentioned military applications — 
where equipment weight and size, fast response times, easy system setup, and real-time 
communication are crucial to the mission success — TwiddleNet shows that the use of 
off-the-shelf devices is an effective, affordable and efficient approach to serve critical 


communication needs in first responder or quick reaction missions. 


B. FUTURE WORK 
1. Security 


Future implementations of TwiddleNet emphasis should be put on secure 
communication beyond the inherited security provided by the wireless environment. 
Because TwiddleNet uses TCP connections as the main protocol, Secure Socket Layer 


(SSL) should be researched. With SSL, the devices are capable of handling certificate 
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authentication, and TwiddleNet could use the existing Private Public Key Infrastructure 
(PKI). A recommendation would be that all devices need to authenticate to the portal, and 
the portal needs to authenticate to the devices using SSL. The resulting peer-to-peer 
connection between two mobile devices would follow the same approach. This bilateral 
authentication is particularly important within any military application of TwiddleNet, 
but also to ensure authentication, identification and confidentiality for social or business 
networking. 

Another, simpler approach is to use a Personal Shared Key (PSK), which could be 
created during account set-up. The initial communication during sign-in could be used to 


create session keys, which would then be used to symmetrically encrypt the messages. 


2. Database 


Currently, we only use the portal database to store content tag information and to 
enable the username-IP address translation. Once an alert from a client is received, the 
portal will query the database for possible users who are interested in the content, and 
their IP address,. The current query will always return all signed-in users. A future 
implementation of the portal should expand user and content attributes, with “grouping,” 
which will allow for more specific queries. User profiles should allow for selecting which 
types of alerts to receive and which alerts to limit, or reject. Portal profiles should allow 
for setting task-specific values, such as a timing limit for the smart caching algorithm. All 
these suggestions could be implemented and managed in a relational database. Depending 
on the query, the portal can then retrieve a specific set of clients that match the 
requirements. This approach will significantly reduce the amount of unnecessary and 


possibly unwanted alert traffic. 


3. Web-based Account Administration Tool 


This tool does not exist. Within the current implementation, user accounts are 
created in the database manually. With the development of a web-based account 
administration tool, a nice interface to the database could be created. This would be the 


ideal means of managing the database for an administrator. It would also be the interface 
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for users to open and manage accounts or perform online searches. This approach allows 
for convenient access from a PC, without the limiting features of cell phones, such as a 


small screen size and small keyboards. 


4. Command Post 


The current Command Post receives alerts and the content. The application 
creates a web page that is then accessible via a normal web browser. This web site 
features a wiki capability, whereby any user can add comments to the xml document. We 
recommend that a future version should provide communication back to the content 
creator. This capability would be especially important for the triage scenario where 


Headquarter personnel could give additional support and feedback to those on the scene. 


5. Software Engineering 


After incremental improvements, development of the TNet components would 
have advanced to the stage where they should be redesigned using a software engineering 
approach. The current version features the required functionalities and offers solutions to 
achieve the desired behavior. The network presented herein is an example of how 
integration between all the components creates a more streamlined application upon 
which an efficient code can be developed. In addition, thorough code documentation 


would be a valuable result of the engineering process. 
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APPENDIX A 


Test results for Test 1: 





Average: 


23 


Test results for Test 2: 


[Percentage |Device1 [Difference |Device2 [Difference || differen 





Average: 


36 


Test results for Test 3: 


[Difference |Device? [Difference] 





Average: 


af 


Test results for Test 4: 


Percentage Jevice1 


TotalTried: 89 
Successful: 89 
Failed: 0 
TotalBytes: 93788111 


TestPicture Size 1053799 


[Differe 


nce [Device2 _|Difference| 


95895709 


82 
82 
0 


86411518 
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Test results for Test 5: 


[Percentage _| 


TotalTried: 409 
Successful: 409 
Failed: 0 
TotalBytes: 431003791 


TestPicture Size 1053799 


418358203 


401 

401 

0 
422573399 
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e[Deviced _ [Difference | 





414143007 


Test results for Test 6: 


[Percentage _| [Deviced _ [Difference | 





TotalTried: 732 736 709 744 
Successful: 732 715 709 744 
Failed: 0 21 0 0 
TotalBytes: 771380868 753466285 747143491 784026456 


TestPicture Size 1053799 
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Test results for Test 7: 


TotalTried: 1025 
Successful: 1025 
Failed: 0 
TotalBytes: 1080143975 


TestPicture Size 1053799 


1079090176 


[Difference [Device2__[Difference [Devi 


1073821181 
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ence [Device4 Difference 








1022 

1022 

0 
1076982578 


Test results for Test 8: 


[Percentage__|Device 3__|Difference[Device4 __ [Difference 





TotalTried: 1347 1288 1246 1248 
Successful: 1034 1288 1244 1248 
Failed: 313 0 2 0 
TotalBytes: 1089628166 1357293112 1310925956 1315141152 


TestPicture Size 1053799 
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Test results for Test 9: 


[Percentage __[Devic [Difference [Device2__[Difference [Devi [Difference [Devices _[Difference 








TotalTried: 1524 1499 1469 1470 
Successful: 1429 1499 1457 1470 
Failed: 95 0 12 0 
TotalBytes: 1505878771 1579644701 1535385143 1549084530 


TestPicture Size 1053799 


43 


Test results for Test 10: 


[Difference [Device2__[Difference [Devi Ic 








TotalTried: 1775 1831 1816 1795 
Successful: 1757 1152 1713 1703 
Failed: 18 679 103 92 
TotalBytes: 1851524843 1213976448 1805157687 1794619697 


TestPicture Size 1053799 
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APPENDIX B 
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Triage Tagging Interface Step 3 
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